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CLINICAL CARE UTILIZATION MANAGEMENT SYSTEM 
PRIORITY CLAIM 

This application claims priority to a U.S. Provisional patent application filed on 
5 November 7, 2000, entitled "UMsource Software," designating Peter Stangel as the 
inventor. 

FIELD OF THE INVENTION 

The present invention related to data processing systems. Particularly, the 
invention relates to a clinical care utilization management system. 

10 BACKGROUND 

Clinical care rendered by physicians and other health care providers is reviewed 
for utilization management, quality of care, and other review or analytic functions by 
reviewing entities charges with these functions. Utilization management is usually 
performed by a health maintenance organization (HMO) or other managed care 

1 5 organization (MCO). 

When a healthcare provider (HCP) examines and treats a patient, the HCP records 
the examination in a clinical chart. Under industry custom, designated personnel at the 
health care site extract clinical information from the chart and transmit the clinical data to 
the reviewing entity by telephone or fax. 

20 At the reviewing organization, personnel manually input this clinical data into an 

electronic form with one or more text fields. The information is then reviewed by one or 
more professional personnel to determine appropriateness of care. Determinations of the 
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appropriateness of care are then communicated back to the health care site by phone or 
fax (negative determinations also require a formal letter of denial). 

Moreover, because the clinical information has been electronically input into text 
fields without any format, the reviewing organization lacks the ability to electronically 
5 evaluate this data for appropriateness of care. Determinations are made manually. 
Determinations are often inconsistent for similar clinical situations by the same reviewer 
or among multiple reviewers. There is almost no way to systematically evaluate this data 
among multiple clinical episodes to see patterns of care. 

As may be gathered from the description above, the process for submitting and 

10 reviewing clinical records is cumbersome and time consuming. Both the HCP and the 
MCO dedicate personnel and other resources to the sole task of managing and processing 
clinical data. Accordingly, there is a need for a system that facilitates the generation and 
processing of clinical records, which provides sufficient data to the MCO, and which 
facilitate the speedy processing and authorizing of the records. 

1 5 SUMMARY OF THE INVENTION 

The invention provides for a centralized system for the submission and automatic 
processing of clinical care transactions over the Internet. The MCO contracts with a 
utilization management organization that employs the invention to facilitate the 
utilization management functions. The MCO agrees on the utilization criteria that are 

20 automatically applied by the utilization system. Health care sites are granted access to 
the utilization system. The health care site employs the utilization system to submit 
clinical transaction data. The utilization system automatically process the data and 
determines whether the transaction is authorized by following the agreed upon utilization 
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criteria. The date is then further submitted to the MCO for record keeping and further 
review if the transaction has not been automatically authorized. 

In one embodiment, the invention provides a computer implemented system for 
generating a medical diagnosis clinical record for submission to a MCO. The system 
5 includes a data entry interface, which facilitates the entry of data corresponding to a 
clinical event corresponding to the clinical diagnosis for that event. The system also 
includes at least one selection interface, which is adapted to facilitate the selection of at 
least one diagnosis. Further, the system includes a navigation module, which facilitates 
the identification of fields for which data should be entered. The navigation module 

10 facilitating the identification of the fields in response to the selection from the selection 
interface. A verification module determines the authorization level for the diagnosis by 
referring to at least the data in the directed-to fields. The verification module determines 
the authorization level prior to the submission of the record to a processing module. The 
invention further facilitates the submission of clinical data over Intranets and other 

1 5 proprietary networks. 

In another aspect of the invention, there is provided a utilization management 
system that authorizes a diagnosis by directing the user to enter all of the required data so 
as to generate a sufficient clinical encounter record to evaluate the record for 
appropriateness of care. The system also automatically evaluates the entered data to 

20 determine an authorization level. The system includes a user interface to facilitate the 
submission of data to the system. The user interface is associated with a forms database 
that is used in generating the user screens by which data is entered. The user interface is 
also coupled to a navigation module that guides the user interaction with the user screens. 
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The navigation module is associated with a selection database that provided information 
as to the data selections that should be available to a user. The user interface is also 
coupled to a verification module that is used to determine a level of authorization and 
criteria compliance based on the entered data. The verification module is associated with 
5 a criteria database that stores criteria rules, which are evaluated to determine an 
authorization level. 

In another embodiment, the system facilitates the generation of encounter records 
that are adapted for automatic authorization processing by a remote system. The 
encounter records include all the data required for determining an authorization level. 

10 The encounter records further provide the data is an objective format that can be 
evaluated without the aid of a human operator. 

In yet another embodiment, the invention provides a two step method for entering 
medical diagnosis data. The method includes entering a criteria into the system. The 
criteria corresponds to a rule required for authorizing a diagnosis. The criteria is also 

15 associated with at least one finding. Finally, the method includes entering a finding into 
the system. 

The present invention also provides an interface for entering data for the 
authorization of a diagnosis. The interface includes a first portion, which is adapted to 
facilitate the selection of a system group. The interface includes a second portion, which 
20 is adapted to facilitate the display and entry of data for the diagnosis. A display area is 
included within the second portion, which is displaying parameter and corresponding 
findings for the selected system group from the first portion. Finally, the interface 
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includes a data entry area, which is facilitating at least the selection of findings and 
parameters for the system group. 

The invention also provides a system where date is entered directly during the 
clinical event on hand-held devices that are coupled to a remote database by a network 
5 interface so as to create a clinical record of the encounter and replace paper clinical 
charting. In one embodiment, the hand-held devices are coupled to the utilization system 
by a mobile network connection. 

The present invention also provides an interface for the authorization of clinical 
care including hospital admission, acuity of level of care for inpatient hospital days, 
10 appropriateness of emergency room visits, and preauthorization of elective medical 
services and hospitalizations. 

In another embodiment, a system in accordance with the invention is implemented 
as a web based system for submitting requests for automatic authorization. A health care 
facility employs a web navigation interface, such as a browser, to connect to the web 
15 based system. Pages axe provided to facilitate the entry of encounter date. The data is 
processed to provide an authorization indication before the pages are submitted. 
APPENDIX 

The specification includes an appendix, Appendix A, which illustrates a 
hierarchal arrangement for an Elements Tree structure of the invention. The appendix is 
20 intended to serve as an integral part of the disclosure, which is provided in this 
specification. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates the logical arrangement of modules in a utilization 
management system in accordance with the invention; 
Figure 2 illustrates an Inpatient Census screen; 
5 Figure 3A illustrates an Admission Clinical screen; 

Figure 3B illustrates a chart section of the Admission Clinical screen of Figure 

3A; 

Figure 3C is a continuation illustration of the chart section of Figure 3B; 
Figure 4A illustrates a Clinical screen; 
10 Figure 4B illustrates a chart section of the Clinical screen of Figure 4A; 

Figure 4C is a continuation illustration of the chart section of Figure 4B; 
Figure 5 A illustrates a Patient Discharge screen; 

Figure 5B illustrates a chart section of the Patient Discharge screen of Figure 5 A; 

Figure 5C illustrates the Patient Discharge screen when post discharge treatment 
15 is selected for the patient; and 

Figure 6 is a flow diagram illustrating a process for entering diagnosis data in 
accordance with the invention. 
DETAILED DESCRIPTION 

The structure and operation of a utilization system in accordance with the 
20 invention will now be discussed with reference to illustrations of an exemplary utilization 
system. First, the structure and operation of system modules will be discussed with 
reference to an illustration of a system arrangement. Next, the structure and operation of 
the system's data entry interfaces will be discussed with reference to illustrations of user 
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screens from a web based utilization system. Finally, the operation of the system when 
submitting encounter data is illustrated with reference to user screens and a flow diagram 
of user interaction steps. 

The present discussion refers to data entry operations in the context of in the 
5 context of user interaction with the system. Such data entry operations are not limited to 
the entry of a textual or numerical values in an entry box but also include the selection of 
data from a pop-up list, the selection of a radio button from a set of buttons, the 
acquiescence of a user with default data that is automatically filled by the system, and a 
check indication in a check box. As may be appreciated, other forms of providing data 

10 are available and are intended to be encompassed within the present discussion when 
referring to data entry. 

The present discussion refers to a "user" interacting with the system. The term 
"user" is intended to encompass an individual member of an organization that interacts 
with the system, several members of the organization interacting with overlapping 

15 portions of the system, or members of different organizations interacting with various 
portions of the system. Moreover, as maybe appreciated, a "user" includes a computer or 
otherwise automated system that submits data to a processing system of the invention. 

Figure 1 illustrates the logical arrangement of modules in a utilization system in 
accordance with the invention. The modules include a user interface 20, a navigation 

20 module 21, and a verification module 22, The user interface 20 generates the user 
screens with which the user interacts to submit or review data. The user interface is 
preferably coupled to a communication link (not shown) that receives user commands 
and data from a network connection. In one embodiment, the communication link is an 
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Internet connection. In another embodiment, the communication link is a local area 
network connection. In yet another embodiment, the communication link is a mobile, 
wireless, remote Internet link. In yet another embodiment, the communication link is a 
proprietary link. 

5 The user interface 20 preferably facilitates the generation of user screen in 

accordance with predetermined screen templates and controls. The predetermined 
templates and controls are advantageously stored in a forms database 25, The user 
interface 20 is further associated with a patient data storage module 23, which stores 
patient data that was entered and submitted to the system. The patient data storage 

10 module 23 also stores general data relating to health care providers, health care facilities, 
and MCOs. The user interface 20 is operatively coupled to the verification module 22 
and to the navigation module 21. 

The navigation module 21 is employed to guide the user in entering data by 
modifying fields of the user screen in response to the user entering data that affects the 

15 navigation path available to the user. Preferably, the navigation module 21 
communicates with the user interface 20 to identify when the user enters data that affects 
the navigation path or otherwise entails a modification of available controls. The 
navigation module 21 is associated with a selection database 24. The selection database 
24 preferably includes data that identifies members of each hierarchal level and the 

20 logical relation between levels. Such arrangement of members and relations is illustrated 
in Appendix A. The example arrangement of Appendix A is for a four tier division. 
However, as may be appreciated, different number of tiers are used in other 
implementations of the invention. 
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The verification module 22 examines the input data to determine whether an 
authorization status or a criteria status should change in response to the input data. The 
verification module 22 is preferably associated with a criteria database 26. The criteria 
database 26 stores rules corresponding to criteria, which are applied to determine whether 
5 a clinical event should be authorized. The criteria are preferably in the form of Boolean 
rules that refer to data fields of the user screens. In one embodiment, the data for each 
field of the user screen is provided to the verification module 22 after the user modifies 
the data in the particular field. In another embodiment, selected fields of the user screen 
are designated to trigger the submission of data to the verification module 22. 

10 In operation, the system provides user screens to the user by employing the user 

interface 20. The user screens include textual displays and data entry controls that 
facilitate the submission of data. Some of the screens presented to the user are static 
screens, whereby the same screen is provided to the user regardless of the data entered by 
the user. Other screens are dynamic screens, whereby the selections and data entry 

15 interfaces depend on previously entered data. In one embodiment, the dynamic screens 
are generated when the user interface 20 employs data from the navigation module 21 in 
combination with controls and form templates from the forms database 25. 

The navigation module 21 preferably receives selections from the user interface 
20. The navigation module 21 responds to predetermined user selections by querying the 

20 selection database 24. In one embodiment, a user selection of a criteria from a criteria 
pop-up list (discussed below) is received by the navigation module 21, which responds by 
searching for the associated element, group, parameter, and findings. In one 
embodiment, when the user selects a criteria, the navigation module 21 queries the 
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database 24 for the corresponding criteria attributes for which data is required. The 
elements database 24 returns selections that are available to the user as a result of the 
newly entered data. The navigation module 21 communicates with the user interface 20 
to modify the available selections in the user screen to conform to the changed navigation 
5 path. In one embodiment, an element, a group, a parameter, and a finding are 
automatically set in response to the selection of a criteria from a criteria pop-up list 
(discussed below). 

The verification module 22 receives user data and determines whether the data is 
sufficient to authorize the clinical event or to satisfy a particular criteria of the clinical 

10 event. The rules in the criteria database 26 preferably include both rules that examine 
data from a single field and rules that examine data from several fields. Rules are 
advantageously structured to progressively determine, first, when a particular criteria is 
satisfied and, second, when a displayed diagnosis is authorized. Advantageously, rules 
are progressively applied to other diagnosis of the clinical event, when the particular 

15 displayed diagnosis is not authorized. Preferably, the rules employ Boolean functions 
and evaluations to define when a criterion or diagnosis is satisfied. In one embodiment, 
data items are combined by using Boolean operators such as AND, OR, and NOT. When 
the user data is sufficient to authorize a diagnosis or satisfy a criteria, the system provides 
a corresponding indication to the user. The indication is preferably provided prior to the 

20 user submitting the record to the utilization system. Accordingly, the verification 
operation is local to the user. In one embodiment, the verification is automatically 
prompted when the user navigates from one screen of the system to another and screen 
data has changed. 
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Preferably, the authorization criteria are set by the agency for which the record is 
intended. The rules are advantageously set by selecting from several sets of rules or by 
independently creating rule sets. As may be appreciated, different agencies may desire 
different rules. Thus, a user that is a customer of an agency is provided access to the 
5 system and is authorized in accordance with that agency's rules. The rules that are used 
for criteria and authorization evaluation are advantageously hidden from the user and are 
only available to authorized personal such as the MCO or the utilization system 
administrator. 

The rule application portion of the utilization system preferably includes rules for 
10 criteria and rules for authorization levels. Criteria rules are used to evaluate whether the 
entered data satisfies a particular criteria that is applicable to the overall authorization 
evaluation. The diagnosis authorization rules advantageously refer to the results of 
criteria evaluations to determine the result and authorization level. The criteria rules 
evaluate the completeness of data in addition to evaluating whether the data satisfies a 
1 5 criteria. As may be appreciated, there can be more than one criteria for a given diagnosis 
authorization. However, at times, a diagnosis is only associated with a single criteria. 
The criteria preferably correspond to major symptoms as well as to the diagnosis. 

In one embodiment, the criteria rule results are indicated by a message in a dialog 
box of the entry form. In another embodiment, the result indication is by an alert window 
20 that is provided when invalid data is entered. 

In one implementation of the utilization system, the modules and databases are 
part of a database application written on a 4™ DIMENSION, ACI database and with 
HTML and JAVA Script interfaces. In another implementation, the database application 



11 



is a front-end for a mainframe database. Preferably, the database application is SSL 
enabled to provide for transmission security over the Internet. The database includes 
proprietary encryption for transmission over its proprietary network. 

Figure 2 illustrates an Inpatient Census screen 29 of a utilization system in 
5 accordance with the invention. A facility identification portion of the screen includes a 
facility type pop-up list 30 to select a facility type. The facility identification portion also 
includes a facility pop-up list 31 to identify a facility from facilities in the network of the 
selected facility type. The Inpatient Census screen 29 also includes navigation buttons 32 
for navigating to an Admit Clinical Screen, a Clinical Screen, and a Discharge Plan 

10 Screen. A New Admit button 27 facilitates navigation to an initial administrative patient 
registration screen (Admission Face screen). Finally, the Inpatient Census screen 29 
includes a display box 33 that displays patient record data for the selected facility for the 
current date. In one embodiment, the displayed patients are all patients belonging to the 
MCO that are hospitalized in the facility. In another embodiment, the displayed data is 

15 for all inpatients at the facility. The display box 33 preferably includes, for each patient, 
the last acute day authorized, the number of days not authorized, last date that clinical 
data was input, admission authorization number, and discharge plan with corresponding 
discharge plan authorization status. 

In operation, the user selects a facility type from the facility type pop-up list 30. 

20 The user then selects a facility from the facility pop-up list 31. The facility name is 
displayed in the corresponding display box 28. Patient data for patients that are in the 
facility during the default period are displayed in the display box 33. The user selects a 
patient record from a line of the display box 33. The user then selects one of the 
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navigation buttons 32 to prompt the corresponding user screen for the selected patient 
record. 

Figure 2B illustrates an Admission Face screen of a utilization system of the 
invention. The Admission Face screen is used to enter patient data for a newly admitted 
5 patient. Such data includes ID number, name, gender, date of birth, admission date, 
attending doctor name, ICD-9 code, admission diagnosis, and any other relevant patient 
information. 

In general, when a patient is admitted to a facility, an administrative admission 
record is created in the Admission Face screen. An Admission Clinical screen is then 

10 employed to submit data for creating and to review an admission clinical record. A daily 
inpatient clinical record is created and reviewed by employing a Clinical screen. Finally, 
a discharge planning record is created and reviewed at any time after admission, but 
preferably early in the hospitalization. 

Figure 3 A illustrates the Admission Clinical screen 34 of a utilization system in 

15 accordance with the invention. The Admission Clinical screen 34 is used to input the 
clinical data from the patient's admission exam. This includes historical data including 
prior surgeries, illnesses, along with the last hospitalizations and emergency room visits 
for these surgeries and illnesses. For example, historical data includes prior operations, 
prior diagnosis, prior treatments, history of symptoms, and other physiological data. 

20 The Admission Clinical screen includes a header area for displaying patient information. 
The header area includes a patient name 38, a patient identification number 39, a patient 
date of birth and gender 37, any discharge plans 35, an admission diagnosis 36, and an 
admission date 40. The admission diagnosis 36 is preferably set after the patient 
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admission diagnosis is entered in the Admission Face screen of Figure 2A. Also, the 
discharge plan 35 is preferably set only after the discharge plan is entered by employing 
the Discharge Plan screen (discussed below). 

A second portion of the Admission Clinical screen is used to select a desired 
5 diagnosis for authorization and to select associated criteria. The second portion includes 
a chart date pop-up list 41, a Patient Location pop-up list 42, a Diagnosis pop-up list 43, a 
Criteria pop-up list 44, a Level Of Care display box 47, an Authorization display box 46 
and an Additional Information Request pop-up list 45. The additional information 
request pop-up list 45 is preferably used to prompt the user for non-diagnosis related 

10 information that is manually reviewed either at the submitting HCP or by the MCO. The 
Diagnosis pop-up list 43 facilitates the selection of a desired diagnosis. In the context of 
the Admission Clinical screen 34, the entered diagnosis is an admission diagnosis. The 
Criteria pop-up list 44 is used to select a criteria that is associated with the desired 
diagnosis. The Authorization Status display 46 provides the authorization level granted 

15 in accordance with the selected criteria. The level of care display box indicates the level 
of care corresponding to any authorization. In one embodiment, the Criteria pop-up list 
44 are preceded by a status designator such as "Needed," "Not Met," and "Met." The 
status designation changes in accordance with the data entered for the criteria. For 
example, when a criteria is fist selected, a "Needed" designation is provided. After all 

20 data is entered for the criteria, the designation changes to one of "Not Met" or "Met." 

A third portion of the Admission Clinical screen 34 is employed to enter 
diagnosis data in a structured manner. The third portion includes several interlinked pop- 
up lists. An Element pop-up list 48 is employed to select a clinical element for the 
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encounter. La the Admission Clinical screen 34, the selected element is set to History, 
corresponding to patient historical information. A System Group pop-up list 51 is 
provided to select a system group of the selected element. The system group is 
preferably a subgroup of the element selected from the Element pop-up list. In some 
5 context, the system group is the body system corresponding to the medical encounter. A 
Parameter pop-up list 52 is provided to select a parameter of the selected system group. 
A Finding pop-up list 53 is used to select one or more findings corresponding to the 
selected parameter. In the Admission Clinical screen further the parameters do not 
require a finding. The Admission Clinical screen includes a past history pop-up list 49 to 

10 select a medical history event type. The screen also includes A last event pop-up list 50 
to select an event. Preferably, the historical data selections are from widely accepted 
diagnosis and procedure codes. History surgeries and diagnosis, ICD-9 code parameters 
and CPT-4 code parameters do not require a finding. 

In operation, the uses selects either Surgeries or Past Diagnosis from the Past 

15 History (Past Hx) pop-up list 49. In one embodiment, the Surgeries are grouped, in the 
System/Group pop-up lists, by CPT-4 Codes. In another embodiment, the Diagnoses are 
grouped, in the System/Group pop-up lists, by ICD-9 Codes. Both sets of codes are 
issued by the AMA. Selecting a CPT-4 code or ICD-9 code in the System/Group pop-up 
list, enters the code with its attendant surgery or illness. 

20 Each input Surgery or Diagnosis is concatenated with the last hospital admission 

episode and/or last emergency room visit, by making selections in the Last Event pop list 
50, which offers a choice of Last Hospital Admit or Last ER Visit. Interval since the last 
event is input in the Duration field and Time Unit pop-up list 63. These last events are 
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concatenated onto the Past Surgery or Past Diagnosis and are displayed in the Current 
Element scroll box 54. 

The fourth portion of the Admission Clinical screen 34 includes a display portion 
and a data entry portion. The display portion is used to display entered parameters for the 
5 selected element in the Element pop-up list 48. For this purpose, a Current Element 
scroll box 54 displays the parameter data along with multiple associated findings. The 
entry portion includes a Parameter display box 55 for displaying the selected parameter. 
The Parameter display box 55 is also used as an entry box is for submitting a parameter 
without using the pop-up list for History and CPT-4 codes and ICD-9 codes or in 
10 preparation for submitting a new parameter. A Finding display box 57 is provided for 
displaying the selected finding data. 

For most findings, selecting a finding in the Finding pop-up list 53 enters the 
selected Parameter with its finding on a line of the Current Element scroll box (as well as 
the appropriate Specific Element scroll box in Figures 3B or 3C). Additional findings for 
15 a Parameter are concatenated on the Parameter line after the initial finding. 

For findings requiring numerical values (such as lab tests, vital signs), the 
Parameter and finding are displayed in the Current Element scroll box 54 only after a 
numeral value has been entered (see below). 

Each input findings is also displayed in entry box 61 and entry box 62 and is 
20 cumulatively added to the Findings pop-up list 59. Findings not requiring numerical 
value (such as lab tests, vital signs) are displayed in entry box 62, while entry box 61 
displays the finding instance of the Parameter (E.g. Finding_l, Finding_2). For findings 
requiring numerical values, the finding is displayed in entry box 61 and the clinical value 
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is entered in entry box 62. For example, if entry box 61 displays "hemoglobin," the user 
would enter "16" in entry box 62 if the patient's lab tests showed a hemoglobin of 16. 

Selecting one of the findings in the Findings pop-up list 59 allows modification 
of, or deletion of, the finding in the Current Element Scroll box. In the Admission 
5 Clinical screen 34, the Finding display box 57 is used to display the last event, which was 
selected from the corresponding Finding pop-up list 50. A pair of entry boxes 61 is used 
to display the selected parameter and finding, respectively. The entry boxes 61 are also 
used to marginally enter data for a finding. Entry boxes 61, 62 are also used to enter 
custom findings not listed in the finding pop-up list 53. 

10 A Time pop-up list 60 is provided to select a time for the event reported. Finally, 

Duration and Frequency entry boxes 63, 64 are provided for submitting a duration or a 
frequency for the reported parameter under the Clinical Element Symptoms. An Interval 
entry box 65 is provided to enter an interval for the reported event. The system 
preferably responds to the data entry by evaluating the admission diagnosis authorization 

15 level. The evaluation is preferably by applying rules to the entered historical data. 
Accordingly, the user is provided with an indication of appropriateness for the selected 
admission diagnosis. Such indication is useful for both treatment of the patient and for 
submitting clinical records to the MCO. 

A Chart Date Navigation pop-up list 41 displays all the dates of the patient's 

20 current hospitalization and enables the user to navigate to any of these dates to review 
date for the selected date. Data may be modified for any date except the admission date 
once the admission has been authorized. The Bed Location pop-up list 42 displays a 
selection of hospital locations, each which may require a different set of criteria to 
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authorize care for the location, e.g. The standard authorization level for a patient in the 
hospital is "acute level of care," however the authorization for a patient in an intensive 
care unit would be "intensive level of care." 

An Acuity Check button 67 is provided on the lower portion of the screen to 
5 prompt the verifying of data if the clinical event did not receive authorization during data 
input. Preferably, the system performs rule checks for the criteria associated with the 
selected diagnosis to determine authorization in a programmatic manner as data is being 
input. The acuity check preformed is advantageously more comprehensive than the 
automatic evaluations in response to data entry in fields of the screen. A Submit button 

10 66 is also available for submitting the screen data to the system and navigating back to 
the Hospital Census screen. Finally, a Reset button 68 is available for resetting the 
screen selections and entries. 

Preferably, the rule associated with the selected criteria is applied to the entered 
data after the user enters data in all required fields associated with the rule. The 

15 authorization status and the status of the criteria are modified in accordance with the 
result of the rule application. As may be appreciated, because an admission authorization 
sometimes depends on more than one criteria, a criteria can be met while the 
authorization status remains as pending status. 

Figure 4A illustrates the Clinical screen 70 of the utilization system. The Clinical 

20 screen 70 includes the same header portion as the Admission Clinical screen 34. The 
Clinical screen 70 also includes the same second portion as the Admission Clinical screen 
34. The third portion of the Clinical screen 70 is different from that of the Admission 
Clinical screen 34. In the Clinical screen, the selection of a criteria from the Criteria pop- 
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up list 44 prompts the navigation of the Element, System Group, and Parameter pop-up 
lists 48, 51, and 52 to the applicable data for the selected criteria. The user then selects a 
finding from the Finding pop-up list 53, If data is required for a finding, the user enters 
the data in the entry portion of the screen. The entry boxes a first box that is used as a 
5 placeholder when data requires only a single entry field, and a second box to enter data. 
The findings available in the findings pop-up list 59 of the data entry portion are the 
findings that have been previously entered for the parameter. Furthermore, in the data 
entry portion Finding pop-up list 59, each finding is preferably followed by the associated 
data for the finding. In the illustrated example, the severity indication from the radio 

10 control box is provided following the finding "wheezing." Preferably, when the "Exam" 
element is selected from the Element pop-up list 48, all possible findings for the 
particular exam are displayed in the Finding pop-up list 59 of the display portion, 
whether selected or not, along with any entered values. 

The display portion also includes a check box 58 to delete the selected finding 

15 from the findings associated with the parameter in the Element scroll box 54. In one 
embodiment, the data entry portion includes a Severity Selection radio-type control 62. 
In other embodiments, the data entry portion includes other control boxes as may be 
required in accordance with the data type assigned to the selected finding. Preferably, 
selecting an element from the Element pop-up list 48 brings up the element data already 

20 entered in the current element scroll box 54. The parameter or finding are 
advantageously not displayed until minimum data is entered. Accordingly, findings that 
require a value, in addition to a selection, are not displayed in the current element scroll 
box 54 until the corresponding value is entered. 
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Figures 3B and 3C and Figures 4B and 4C illustrate chart notes portions 80 of the 
Admission Clinical screen 34 and of the Clinical screen 70, respectively. The illustrated 
portions 80 are preferably visible to the user when the screen is scrolled down by 
employing scrollbar controls of a browsing interface. The chart notes portion 80 includes 
5 a separate scrollbox display for each element available to the user in the corresponding 
screen. Each display scrollbox includes the data that was entered for the corresponding 
element. Preferably, each display scrollbox includes a control whereby when the user 
selects a data line from the scrollbox, the corresponding data is made available in the 
entry portion of the corresponding screen and is displayed in the current element 
10 scrollbox 54. Accordingly, the user is able to browse the data that was entered for each 
element and to modify the entered data by selecting the data display line in the chart 
notes portion 80. 

Figure 5 illustrates a Discharge screen 71. The Discharge screen 71 is used to set 
patient discharge actions and other post-encounter actions, The disposition screen 71 

15 includes a first portion that displays patient information. The first portion is the same as 
the first portion of the Clinical screen 70. A second portion of the screen includes a 
Disposition Location pop-up list 73. The disposition location is the facility or service 
that the patient requires after discharge. The simplest and most common discharge plan 
is disposition to home with no post discharge support services. However, many patients 

20 require various support services to maintain wellness post discharge at home, or may be 
discharged to another inpatient facility that provides services at a lower level of care. 

A third portion of the screen includes an Item Type pop-up list 74, and a 
collection of follow up action check boxes 79. The Item Type pop-up list 74 includes a 
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DME entry to select Durable Medical Equipment. The Item pop-up list 75 is used to 
select an item the item type previously selected. Such Item selections include equipment 
and treatment plans, depending on the applicable discharge plan. A fourth portion of the 
screen is used to provide vendor information for the selected item. The fourth portion 
5 includes a Vendor Location pop-up list 85, and a Vendor pop-up list 84. A scroll box 72 
for entering anticipated clinical status on discharge is also provided. In one embodiment, 
the selected item and findings for the discharge status conform to a discharge rule. The 
disposition data in the Disposition pop-up list 72 is preferably provided as part of the 
header on the Clinical Screen to and on the Admission Clinical screens 34. Preferably, 

10 once a vendor is selected, the display area 76 updates with the entered item data. The 
Discharge screen 71 is also used to enter a discharge plan for a patient. 

In operation, the user selects a disposition location for the patient. The location is 
home, or one of several other post treatment facilities. After selecting a location, the user 
is presented with corresponding pop-up list entries. For example, when a facility is 

1 5 selected as the location, available post-discharge treatments are provided in the Item pop- 
up list 74. In one embodiment, the utilization system automatically reviews the discharge 
plan to ensure that the plan is appropriate to the patient's level of functioning and 
expected needs at discharge. In another embodiment, the discharge plan is submitted to 
the MCO for manual review. 

20 Figure 5B illustrates a chart area of the Discharge screen. As discussed above 

with reference to Figures 3B, 3C, 4B, and 4C, the chart area is a bottom portion of the 
corresponding screen, which includes individual display scrollboxes for elements of the 
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screen. In the context of the Discharge screen, the chart area 92 includes scrollboxes for 
Discharge Plans, Clinical Status, Clinical Needs, Exam, and Rx. 

Figure 5C illustrates a Discharge screen 71 with data selections for a post- 
discharge treatment facility. The selected disposition from the Disposition Location 
5 control 73 is Skilled Nursing. The item selected for the disposition is of Needs PRI 
submission. The vendor location of Nyack is selected. The vendor of Sunrise Nursing 
Home is selected from the vendor pop-up list. As discussed above, the vendor details are 
displayed after the vendor is selected from the vendor pop-up list. 

Figure 6 is a flow diagram illustrating the process for submitting medical 

1 0 encounter data in the Clinical screen 70. The user starts by selecting a diagnosis from the 
diagnosis pop-up list 43 (step 95). The user has two options in submitting encounter data 
to the system, A first option is a two-step entry procedure. First, the user selects a 
criteria from the criteria pop-up list 44 (step 96). The criteria selection results in the 
automatic population of the element, system group, and parameter pop-up lists 48, 51, 

15 and 52. The user then selects from the Finding pop-up list 53 (step 97). 

Alternatively, the user employs the second entry option, which is to progress 
through the hierarchal pop-up lists in the third portion of the Clinical screen 70. The user 
selects an element from the Elements pop-up list 48 (step 98). The system searches for 
groups that are associated with the element. Preferably, the navigation module 21 

20 searches the selection database 24 for associated groups. The navigation module 21 then 
identifies the groups that should be made available in the System Group pop-up list 51. 
The user then selects a system group from the System Group pop-up list 51. The system 
then employs the navigation module 21 to identify the parameters associated with the 
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selected system group. The associated parameters are then made available for user 
selection from the Parameter pop-up list 52. The user selects a parameter from the 
Parameter pop-up list 52 (step 100). The system then employs the navigation module 21 
to identify the data range and format for findings that are available for the parameter. 
5 The findings, including the associated data ranges and formats are employed to provide 
the user with a selection and entry interface for findings. The user then selects a finding 
from the Findings pop-up list 53 (step 97). 

The system then determines if additional data is required for the finding (step 
101). If additional data is required for the selected finding, the user employs the provided 

10 interface to enter the data (step 102). For example, when the needed data is a severity 
indication, the user selects a severity from a radio control button. 

After receiving all the required data for the selected finding, the system adds the 
selected finding to the findings associated with the selected parameter. The system 
determines if the parameter is a new parameter that is not in the parameter list for the 

15 current element (step 103). If the parameter is not a new parameter, the finding and any 
associated data is added to the corresponding line of the parameter list (step 104). If the 
parameter is a new parameter, the parameter is added as a new line to the parameter list, 
along with the corresponding finding and any associated data (step 105). hi one 
embodiment, the selected finding, along with its associated data, if any, is added to a 

20 display scrollbox where all findings for a parameter are provided on one line of the 
display box. The system then preferably stores the user entries and proceeds in 
accordance with user selections to authorize the record or format the record for 
submission to an authorization agency. 
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In another embodiment, the data is directly entered by a doctor or a treating nurse. 
The data is entered by employing a mobile personal data appliance such as a PALM 
computing device. The mobile device interacts with the server and specially configured 
user screens to enter patient and treatment data, as discussed above. Therefore, there is 
5 no need to use paper data recording that are later entered into the utilization server by an 
operator. 

Preferably, the screens of the utilization system are web page screens. The 
controls are common web page controls, as is known. The data is preferably provided to 
the authorization agency as part of digital reporting and records. In one embodiment, a 
1 0 text file is transmitted to the agency on a weekly basis. 

In other embodiments, the MCO employs the system only for gathering data from 
clients without the automatic evaluation of authorization status. 

Although the present invention was discussed in terms of certain preferred 
embodiments, the description is not limited to such embodiments. Rather, the invention 
15 includes other embodiments including those apparent to a person of ordinary skill in the 
art. Thus, the scope of the invention should not be limited by the preceding description 
but should be ascertained by reference to the claims that follow. 
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